Added Generated Files For SPIR-V Builder #841
Conversation
|
Oops, looks like some of the Site files got added to this commit somehow. I'll fix that. |
|
Question: What should I do about the Rider files that got committed? I'm guessing we don't want those. |
|
Hi, thanks for this awesome project, I'm really looking forward to use SPIR-V backend. I'm trying to build a C# to WGSL (WebGPU's shader language, which should be convertible with SPIR-V) and other shading languages transpiler, after some experiment using ILSpy and syntax level translation, I found it might be better to define a IR for target language is really required (instead of directly translating C# AST into target language string. Although I what I want to build is more graphics/rendering focused, but a runtime compiler from C# IL to SPIRV might be enough for this. I'm trying to find out if there is possibility to contribute on this, but currently struggling in understanding how to add SPIRV backend. Could you please tell me is there any suggestions on how to start learn/plan or steps could be done to add SPIRV backend? Thanks |
|
Hi! Sorry for the late reply. To add SPIR-V as a backend, you would probably need to implement a Backend using the SPIR-V builder that is introduced in this PR. The existing OpenCL and PTX backends may be good to look at for inspiration---they both may have relevant pieces. I imagine the SPIR-V backend might end up being more similar to the PTX backend just because it's also a bytecode, but I'm not sure which language SPIR-V has more in common with. I would also check out the SPIR-V specification. The other piece that would probably be needed is a Vulkan runtime. Again, the CUDA and OpenCL runtimes are probably a good reference, though I don't know much about Vulkan at all, so I can't say how similar the process would be. |
Hello!
Sorry for the delay on this PR, but I think I'm finally done. There are, however, a few minor issues I want to ask about:
SPIRVWord.csthere is an extra allocation here that could be avoided by usingMarshalbut there is a readability tradeoff. There are other minor things like this that can be improved if necessary.
3. Finally, the signature of
Mergefor builders currently looks like this:which is not type safe, as the compiler will allow a string builder to be merged with a binary builder. Can anyone think of a way of making this type safe without having to resort to
ISPRIVBuildergeneric over the implementing type, which would require specifying the builder we want to use everywhere and throw away the advantages of using an interface?Thanks for reviewing!